Presence systems generally relate to systems where a subscriber, usually called a watcher, accesses in order to receive information or notifications about at least presence of other users, called presentities or contacts, from a presence service in charge of managing and updating said information.
Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Presence is one of said presence systems, and is based in users subscribed to a presentities list through only one Session Initiation Protocol (SIP) SUBSCRIBE message sent to a Resource List Server (RLS) which stores and updates said presentities list, or users subscribed to individual Presentities through a set of SIP SUBSCRIBE messages sent to a Presence Server (PS).
Sometimes a watcher is not prepared to watch said information and/or does not want to be bothered by constantly receiving updated presence information.
There are several proposals regarding the optimization of the presence notification receptions.
One of said proposals is described in the Internet Draft, here cited as “work in progress”, “Problem Statement for SIP/SIMPLE” by A. Houri from IBM, T. Rang from Microsoft Corporation, E. Aoki from AOL LLC, V. Singh, H. Schulzrinne from Columbia U., Feb. 26, 2007, (accessible at http://www.softfront.co.jp/tech/ietfdoc/org/draft-ietf-simple-interdomain-scaling-analysis-00.txt).
In said draft it is suggested to optimize the reception of presence notification. In section 7.4 it is described that watchers need not be notified about every presence update of all the contacts at all times. For some contacts watchers may only want to know their presence information when they want to start a communication session. It is proposed to label this as on-demand presence and to accomplish it by using fetch based SUBSCRIBE with expiration interval set to zero. Said approach requires a mechanism in the watcher application to enable watchers to indicate that they only require presence information when starting a new session. Examples may include services, where contacts presence status does not have to be seen or known to a watcher all of the time. It is given as an example a cell-phone associated watcher who may need presence updates only when the cell-phone application (e.g., phone book) runs in the foreground on the device. In section 7.6 other kind of optimizations are described, based on using different kinds of filters applied to presence documents, limited intervals updatings, partial notifications including only what was changed in the presence document from the last sending, and suppressing the sending of unnecessary notifies when for example a subscription is refreshed. In section 7.3 it is described to use a “time presence” status in order to receive only availability information of certain presentities rather than getting notification for every status change of the presentity.
Another of said proposals is described in the Internet Draft, here also cited as “work in progress”, “Composing Presence Information” by H. Schulzrinne and R. Shacham from Columbia University, W. Kellerer, S. Thakolsri from DoCoMo Eurolabs, Dec. 27, 2006, (accessible at http://www.potaroo.net/ieff/idref/draft-schulzrinne-simple-composition/).
In section 5 of said draft it is described to provide information to the watcher indicating communication capability of the presentities, according to different “busy status” generally indicated by the user o automatically, including for example when said presentity is “in a car”, “on-the-phone”, “in a place that does not allow for private communications”, or complex rules derived that involve outside information such as time of day, such as for example, when user-input is “idle” between certain hours of the night, the user's activity should be set to “sleeping”.
Still another of said proposals is found in the Internet Draft, here also cited as “work in progress”, SIMPLE made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence using the Session Initiation Protocol (SIP)” by J. Rosenberg from Cisco, Jun. 23, 2007, (accessible at http://ietfreport.isoc.org/idref/draft-rosenberg-simple-simple/).
Section 2.5 of said draft relates to optimizations regarding presence notifications sent to the watcher. It proposes to use a mechanism that allows a watcher to include filters in its subscription, which limit the cases in which notifications are sent.
EP1441486A2 describes a presence system and a presence notification destination controlling method, used to send presence notifications only to specific subscribers, as a function of, for example, notification destination determination rules including notification conditions designated by subscribers, or according to the attributes of the subscribers. Different examples of rules based on said subscribers attributes are given in the description, such as: “Notify the first subscriber to perform a subscription”, “Notify subscribers belonging to a specified group” and “Notify subscribers belonging to the private group if the presence for the presentity is “Free””.
US2007033278 concerns to a method and apparatus for providing a list-based service. It proposes to provide a notification when the list members state satisfy some conditions, such as that the presence state has or has not changed during a time interval, or that it has or has not changed a threshold amount, etc. These conditions can be indicated by the watcher by an indication comprised at the subscription. In said document is not described to apply said conditions to the watcher.
It is not known in the cited prior art, to optimize the presence notification receptions according to states of the watcher different from an active, terminated or pending state, i.e. to stop sending presence notifications to the watcher while he is in an idle on-hold or suspended state, but has not terminated its presence service subscription.